1. Field of the Invention
The present invention relates to network security and, more particularly, to firewalls and to handling related connections in firewalls.
2. Description of the Related Art
Traditionally, a firewall is considered as a set of components forming a gateway between two or more networks, which have different security requirements. Thus, a firewall is a gateway which operates at the same time as a connector and a separator between the networks in a sense that the firewall keeps track of the traffic that passes through it from one network to another and restricts connections and packets that are defined as unwanted by the administrator of the system. Physically a firewall is a device with appropriate software to do the tasks assigned to it. It can be a router, a personal computer (PC), or whatever device that can be used for such purposes.
A firewall is configured by means of rules (forming a rule base), which define which data packets are allowed to traverse the firewall and which are not. A rule comprises information for identifying a data packet (e.g. source and destination addresses and ports) and an associated action, which may be for example to allow or deny the packet. Usually everything that is not explicitly allowed in the rules is denied. The action may be also something else than simply allow or deny. For example, the action defined in the rule may indicate that some further action needs to be taken before releasing a data packet, which is in principle allowed. Such further processing may be for example network address translation (NAT), encryption, decryption or virus checking. Also deny action may include further processing. For the sake of simplicity, mainly only the actions deny and allow are discussed herein, however, the possibility to have further processing associates with these actions is not excluded.
A firewall may be a simple packet filter, which compares header fields of a data packet to the rule base and processes the data packet according to the rule, which matches the data packet. A more advanced, stateful firewall keeps track also on the state of different connections. The principle in a such firewall is the following: when a data packet, which is opening a new connection, arrives at the firewall, it is checked on the basis of the rule base, whether the connection should to be allowed or denied. If the connection is allowed, an entry is added to a table of open connections (connection state table), and otherwise the data packet is simply discarded. A data packet, which is not opening a new connection, is compared to the connection state table instead of the rule base. If the corresponding connection exists in the table the data packet is allowed and otherwise denied. Further, the state of the connection may be maintained in the corresponding entry of the connection state table. In this way only data packets belonging to valid open connections are allowed to traverse the firewall.
Some data transfer protocols consist of more than one separate connection. For example, a first connection is opened and then at least one other connection is opened on the basis of information obtained from or transferred within the first connection (see e.g. U.S. Pat. No. 6,219,706). That is, some attributes of the other connection are negotiated within the first connection. These are herein referred to as a parent connection (the first connection) and a related connection (the other connection). Such a related connection is always related to some parent connection and does not exist alone in a sense that opening the related connection requires intervention of the parent connection. However, the parent connection may be terminated before terminating the related connection. In addition, one related connection may be a parent connection of another related connection. This concerns for example H.323 protocol. For these protocols the method of allowing connections described above needs to be further adjusted, since the details of the related connection may not be known beforehand.
For example in FTP (File Transfer Protocol) the opening and attributes of a data connection between a server and a client are negotiated in a separate control connection. (That is, the data connection is a related connection and the control connection is a parent connection.) In order for the FTP to work through a stateful firewall, an entry corresponding to the data connection needs to be stored in the firewall (e.g. in a table of related connections or in a connection state table) on the basis of the contents of the control connection. Since (all of) the attributes (e.g. ports) of the data connection are not known beforehand, a firewall rule allowing one specific data connection cannot be defined. Moreover, it is desirable to allow the data connection only for the time it is needed for legitimate use. One solution for this is to have a separate processing module, which monitors the FTP control connection, detects the attributes, which are negotiated for the data connection, and stores the details of the pending data connection in the firewall. An entry corresponding to the attributes may be added into a separate table of related connections or an entry may be added straight to the connection state table. Then, when the first packet of the FTP data connection arrives at the firewall, it is allowed on the basis of the entry already created by this separate processing module and no rules are needed for allowing the data connection.
It is possible, that such a separate module is produced by someone else than the party, who is administering the firewall. For example an MSP (Managed Service Provider) or an MSSP (Managed Security Service Provider) may offer firewall services to customers so that the firewall is administered by the MSP or MSSP and possibly internal networks of more than one customer are secured by one firewall. One such network configuration is shown in FIG. 1. An MSP offers firewall service for customers A and B. Thus, A and B connect their internal networks 100 and 102 to the Internet 104 via the firewall 106, which is administered by the MSP. The MSP manages the firewall 106 from its internal management network 108. In this kind of arrangement, the customers subscribe certain kind of protection from the MSP and the MSP provides the firewall with appropriate rules. However, customers may be assigned to administer a certain subset of firewall rules, which are specific to their network. Alternatively, the customers may not be able to (and they may not need to) modify the rules of the firewall.
Nevertheless, some customers may need to use some special protocols, which consist of more than one connection and require a separate processing module described above. Such special protocols are used especially in financial and banking sector. For increased security such protocols may further be unpublished and/or customer specific. In such situations the MSP may provide the customers possibility to design their own processing modules, called customer protocol agents herein.
This, however, creates a potential security risk. The customer protocol agent needs to have ability to add connections to the connection state table of the firewall in order to be able to provide the required functionality. The firewall administrator (e.g. the MSP), on the other hand, does not have possibility to limit the capability of the customer protocol agent to allow new connections as in principle the protocol agent could add any connection to the connection state table and, if a connection exists in the connection state table, it is allowed by default. Therefore, the customers may implement either accidentally or purposefully malicious protocol agents, which allow illegitimate connections through the firewall.
One solution for this problem is to include in the rule base special rules for related connections. In this case a related connection is added to the connection state table only if there is a rule, which allows such related connection. With this solution it is possible to allow or deny all related connection to some address/port. However, most often the need is to allow some legitimate related connections and to deny others. But it is impossible to know beforehand the exact details of these legitimate connections; e.g. the ports that related connections are using may vary over time and more than one protocol may use the same ports for related connections. Therefore this solution is insufficient and not flexible enough especially for MSP or MSSP use and a new solution is needed.